Blog

今月で Google Cloud の Professional 認定資格を全冠しました。このブログでは、Google Cloud 認定の受験を検討している方に向けて、試験で問われる内容や私がとっていた勉強方法、対策について紹介したいと思います。試験内容は頻繁にアップデートが入るので、最新情報や詳細な出題範囲については公式サイトの試験ガイドを確認してください。

Google Cloud のデータベースソリューションへの移行を支援するフルマネージドなマイグレーションサービスとして Database Migration Service（DMS）があります。DMS は、オンプレミスまたは他のクラウドサービスから Google Cloud へのデータベース移行、もしくは Google Cloud プロジェクト間でデータベース移行する際に、複雑な作業プロセスをマネージドに実行・管理してくれます。データベースの移行作業は、例えば初期データのダンプとインポート、アプリケーションが稼働している間の更新データの整合性の確保、スキーマの互換性チェックと調整、最終的なマスター昇格作業といった多くのステップが必要になります。DMS では、これらのプロセスを一元的に管理して複雑な移行プロセスを支援するように設計されています。直近、Google Cloud プロジェクト間で Cloud SQL を移設する際に DMS を使ったマイグレーションを実施したので、今回のブログでは DMS の紹介を交えつつ、データベース移設手順について紹介したいと思います。

複数の Google Cloud プロジェクトに跨るリソース間の通信が発生する場面では、VPC ネットワークを通じて安全に接続できる仕組みが必要です。Google Cloud では、主に Cloud VPN によるプライベート接続で VPC 間にトンネリングを構築する方法、VPC Peering で VPC 間を直接接続する方法、比較的規模の大きいサービスでは Shared VPC を利用してネットワークを共有する方法等があります。中でも Cloud VPN を使用した接続は、プロジェクト間を柔軟かつセキュアに接続したい、異なるネットワーク構成を維持したまま通信させたいといった場合に有効です。Cloud VPN は、トラフィックの暗号化や論理的なネットワーク分離を重視するケース、推移的ルーティングが必要となる場面で多く採用されています。今回のブログでは、Cloud VPN を利用して異なるプロジェクトの VPC をセキュアに接続する方法について紹介したいと思います。

2025 年 4 月 1 日から Docker Hub の Rate Limit が引き締められ、未認証ユーザによるイメージ Pull は 1 時間あたり 10 回まで に制限されました。Rate Limit に引っかかると、Docker Hub からのイメージ Pull が一定の期間規制されるため、コンテナが起動できなくなる危険があります。 特に、マネージド Kubernetes の場合、イメージ Pull はクラスタの IP（NAT IP 等）アドレスを送信元としてリクエストされるため、同一の IP アドレスから大量の Pull リクエストを送信すると、その IP に対して Docker Hub の Rate Limit が適用されます。このため、単一の Pod が Rate Limit に引っかかると、他の Pod もイメージの取得ができなくなり、ImagePullBackOff や ErrImagePull に陥る可能性があります。今回は Google Cloud Artifact Registry の Remote Repository と Amazon ECR の Pull Through Cache を活用した Docker Hub の Rate Limit 対策を紹介したいと思います。

2024 年 10 月から約 3 ヶ月に渡り Google Cloud が主催する Google Cloud Innovators Gym #9（通称 G.I.G.）というプログラムに参加してきたので、振り返りも兼ねてブログを書きたいと思います。 今後参加される方や、Google Cloud 認定資格試験を受けようと考えている方に向けて、何かの参考になれば幸いです。

システムの監視は安定した運用を維持するために欠かせない要素です。 モニタリングの一環として「アラーティング（警告通知）」を整備することで、システムの異常を早期に検出して適切な対応を取ることでダウンタイムの回避やパフォーマンスの最適化を図ることができます。今日、Grafana は OSS として公開されているダッシュボードツールのデファクトスタンダードとなっています。 Grafana はメトリクスの可視化やデータ分析の機能だけでなく、アラート機能を活用することでシステムの異常をリアルタイムに検出し、担当者に迅速に通知することが可能です。 最新の Grafana バージョンでは、アラート機能が大幅に強化され複雑な条件設定や通知チャネルの多様化に対応しています。Grafana Alert は単純なクエリや閾値に加え、ポリシを設定することで通知のタイミングを柔軟に制御することができます。今回のブログでは、Grafana Alert の機能について基本的な仕組みやアラートの制御方法について整理したいと思います。

Kubernetes には Pod の配置を制御する機能があります。 Pod の配置制御とは、任意の Pod を特定のノードにスケジュールしたり、逆に特定のノードに対して Pod をスケジュールさせないようにコントロールすることです。最も簡易的な方法として、Node Selector を使用することで任意の Pod を所定のノードにスケジュールすることができます。 また、Node Selector に加え、より細やかな制御が可能な Node Affinity を使用することもできます。Node Selector および Node Affinity が、ある Pod を特定のノードにスケジュールさせるために使用されるのに対し、Pod をあるノードから遠ざけたい、または特定のノードをワークロードから隔離したいという要件に対しては Taints/Tolerations という機能が用意されています。 Taints と Tolerations は互いに作用しあい、Pod が不適当なノードにスケジュールされるのを防ぎます。Node Affinity の場合は、未指定の場合、どのノードにでも Pod をスケジュール可能ですが、Taints/Tolerations の場合は、指定しない限りそのノードに Pod がスケジュールされることはありません。Taints/Tolerations は、例えば Production 用のノードには他の Pod をスケジュールさせたくない場合や、GPU（Graphics Processing Unit） や FPGA（Field Programmable Gate Array） 等の特殊なデバイスを持つノードには特定の Pod 以外をスケジュールさせたくないといった場合に有効です。今回のブログでは、Taints/Tolerations による Pod の配置制御とノードの隔離策についてまとめたいと思います。

昨年 12 月 2 日 - 6 日までの 5 日間に渡り、米 Las Vegas にて AWS re:Invent が開催されました。 今回は、次世代 SageMaker の発表や Bedrock・Knowledge Bases の機能強化、Nova のマルチモーダル画像・動画生成モデルの提供開始等、生成 AI に関する話題が盛りだくさんでした。中でも個人的に興味深かったのが EKS Auto Mode の発表です。 これまでの EKS は、Control-Plane に関してある程度の機能がマネージドに提供されているものの、Google Kubernetes Engine（GKE） と比較してネイティブな Kubernetes を運用しなければならない印象でした。また、手動でのクラスタアップグレードが必要な上、Data-Plane（ワーカーノード）の運用自動化も提供されておらず、ある程度インフラの知識を持ったエンジニアによる戦略的なメンテナンス作業が必要でした。EKS Auto Mode では Kubernetes に必要なコンピュートリソース、ストレージシステム、ネットワーキング機能のプロビジョニング自動化等、従来の EKS と比較してクラスタの管理コストを大幅に下げることが期待できます。今回は、そんな EKS Auto Mode の特徴や仕組みについて、個人的な所感を交えつつ紹介したいと思います。

Kubernetes API はクラスタリソースを操作するための基本的なインターフェースを提供します。 クライアントは Kubernetes API を通じて、Namespace, Deployment, Pod 等の Kubernetes の様々なオブジェクトを検索・操作することができます。Kubernetes API はクラスタのアップグレードに伴い、既存の API が非推奨（Deprecated）または廃止（Removal）となる場合があります。 もし、非推奨 API でサービスを運用し続けると、いずれ API が使用できなくなりサービスのダウンタイムや障害を引き起こすリスクが高まります。 実際に米国ソーシャルニュースサイト Reddit の例 にあるように、非推奨 API を使用し続けたことで大規模な障害が発生した事例も報告されています。Kubernetes の API サーバは API のバージョン情報を管理しており、Deprecated API を適用すると、以下のようなメッセージで警告を出してくれます。これは v1.21 のクラスタに対して、batch/v1beta1 の CronJob を利用したリソースを定義したマニフェストを Apply した際に返される結果です。 kubectl が Warning を返しているのが分かると思います。今回のブログでは、Kubernetes が非推奨 API を検出する仕組みについて紹介したいと思います。

Kubernetes はコンテナ化されたアプリケーションのデプロイ、スケーリング、管理を自動化するための強力なプラットフォームエンジンです。 マニフェストを用いてリソースの種類や制御パラメータを組み合わせることで、アプリケーションを柔軟にデプロイ・管理できますが、運用面での統制やセキュリティの確保が課題となっています。 組織全体で一貫したポリシを確立し、セキュリティ要件を設けることは、運用の安全性を確保する上で非常に重要になります。また、インフラ・プラットフォームサイドのエンジニアが継続的に介入せずとも、開発者が自立して安全にアプリケーションを開発できるように舗装することは Platform Engineering の文脈でも必要になってきます。今回のブログでは、ポリシ整備ツールのデファクトスタンダートとなっている OPA（Open Policy Agent） および Gatekeeper を取り上げ、Kubernetes に対するデプロイメントを制御する仕組みについて紹介したいと思います。

Google Kubernetes Engine（GKE）は Google Cloud が提供するマネージド Kubernetes サービスで、クラウドネイティブなアプリケーションの実行基盤として広く利用されています。 Kubernetes クラスタの運用において、アップグレード作業はセキュリティの確保や新機能の利用のために不可欠なプロセスです。一方、Kubernetes のマイナーリリースは 通常 3 - 4 ヶ月に 1 回のペースで実施される上、アップグレード作業にはいくつもの考慮事項があるため、メンテナンスコストが高くなりがちです。また、マネージド Kubernetes の場合、サポートを受けられる期間も限られているため、継続的なクラスタバージョン追従が必要になります。このような GKE のメンテナンスに関する課題に対して、Google Cloud は作業負荷を下げるための仕組みを用意してくれています。このブログでは、GKE の効果的なアップグレード戦略について Google Cloud の内間さんが出している こちらのスライド を参考にまとめてみます。

先日開催された Qiita Hackathon 2024 に参加をし、無事に予選を通過してきたので、振り返りも兼ねてブログを書こうと思います。

フロントエンドアーキテクチャとして Feature-Sliced Design（FSD） と呼ばれる設計手法が注目されています。 FSD は、特にマイクロサービスを採用しているような大規模かつ複雑なシステムの開発現場において、生産性の向上が期待されており、アジャイル法や DevOps との親和性も高いとされています。FSD はシステムを構成する機能や特性（Feature）を スライス（Slice） と呼ばれる単位で細分化し、それぞれが独立性を持つことで全体の設計や変更を容易にするというものです。 スライスの考え方により、複雑な機能を把握しやすくなり、サービス規模拡大に伴うスケーラビリティを担保することが期待されています。FSD は、言語問わずあらゆるフロントエンドアプリケーションに適用できますが、今回は特に Web フロントの設計に焦点を当てて紹介したいと思います。

8 月 1 - 2 日（2 Days）パシフィコ横浜にて開催された Google Cloud Next Tokyo'24 に現地参加してきました。基調講演では主に生成 AI の最新動向や将来性について、実際の活用事例や今後の展望、使用していく上での課題や解決策に関する話題がメインでした。今回のブログでは、基調講演をはじめ、いくつか気になったセッションに関してまとめようと思います。

マルチクラウド環境において、AWS から GCP のマネージドサービスに対し、OIDC によるキーレス連携を実現する GCP Workload Identity Federation の仕組みについて紹介します。多くのクラウドサービスでは、API キーや Credential（AWS アクセスキーや GSA アカウントキー）を発行することで、各種マネージドサービスにアクセスすることが可能です。しかし、永続的に使用できてしまう認証情報は、キーローテーションによる管理の煩雑化や、流出によるセキュリティリスクが存在します。GCP Workload Identity Federation では、Credential として有効期限の短い STS トークンで認証・認可を行うため、前述のセキュリティリスクを軽減できます。これらの処理はクライアントライブラリによって隠蔽されるため、サービスの開発者やワークロードは OAuth 2.0 Token Exchange の複雑な仕組みを意識することなく、通常の Credential と同じように利用することができます。GCP Workload Identity Federation は非常にセキュアで利便性が良いですが、内部でどのような手続きが行われているのか気になったので DeepDive してみました。

Next.js v13.4 で安定版（stable）がリリースされた App Router は Server Components を活用した新しいルーティングとレンダリング機能を提供しています。この WEB サイトも Pages Router から App Router に置き換えたので、今回のブログでは App Router の紹介を交えつつ、移行プロセスについてまとめたいと思います。

5 月 28 - 30 日（3 Days）Google Cloud が開催する Platform Engineering のハンズオンセミナーに参加してきました。 今回のセミナーは Google Cloud カスタマーエンジニアの公演を聞きながら、Google Kubernetes Engine（GKE）を活用して実践的に Platform Engineering を学ぶコンテンツとなっており、座学とラボの両方が実施されました。今回のブログでは、振り返りも兼ねて 3 日間の参加レポートをまとめたいと思います。

サイバーエージェント新卒研修にて『生成 AI を用いた SNS』というテーマで 3 週間の短期開発に取り組みました。僕たちのチームは 'AI で生成した美女' を共有する SNS アプリケーションを開発し、成果発表では インフラ部門で技術賞 を頂きました。今回のブログでは、開発したサービスと実際に構築した運用アーキテクチャについて設計思想や技術選定を交え、紹介したいと思います。

Kubernetes でリクエストを Pod に負荷分散する際にクライアントの送信元 IP アドレスを保持したいケースがあります。LoadBalancer や NodePort を使用する Service の場合、負荷分散の過程で送信元 IP アドレスが NAT（SNAT：Source NAT）されるため、Pod に到達するパケットからはクライアントの IP アドレスを知ることができません。Service の External Traffic Policy を Local に設定すると、外部からのトラフィックは受信したノード上の Pod にのみ転送されるため SNAT は回避できますが、単一ノードにトラフィックが集中するためクラスタワイドな負荷分散ができません。また、Ingress Controller を利用すると HTTP X-Forwarded-For ヘッダに送信元情報を付加することができますが、L7 LB が前提となるため、L4 LB のような低レベルロードバランサでは有効に機能しません。ベアメタル Kubernetes でネットワークロードバランサをプロビジョニングするための代表的な OSS に MetalLB があります。MetalLB には L2 モードと BGP モードの 2 種類の負荷分散方式が用意されています。多くの場合は前者が利用されますが、後者の BGP モードでは、より柔軟なネットワーク構成や負荷分散の制御が可能になり、送信元 IP アドレスを保持したままリクエストを分散することができます。今回のブログでは、MetalLB の BGP モードを利用して SNAT を回避しつつ、クラスタワイドな負荷分散を実現する構成について紹介したいと思います。

Hi there, Happy New Year! 🐉 I'm about to embark on a journey that's both for an IEEE international-conference and my graduation trip. My destinations: Hawaii (Oahu) and Las Vegas, USA. The International-Conference on Consumer Electronics (ICCE) and Consumer Communications & Networking Conference (CCNC) are academic conferences hosted by Institute of Electrical and Electronics Engineers (IEEE). These events focus on discussing the latest research and technological advancements in consumer electronics and communication technologies. Last year, my demonstration paper was accepted at CCNC 2024. I will be presenting the concept of the CYPHONIC adapter demonstration, which I've been researching and developing. A few of my colleagues will also be presenting at the conference. After the international-conference, I plan to visit CES 2024 as well. I'll be updating this blog daily as a travel diary. Alright-off I go! ✈️

サーバ仮想化技術は、物理サーバのコンピュートリソースを最大限活用するために、従来から利用されてきました。 サーバ仮想化を実現する代表的なハイパバイザに KVM（Kernel-based Virtual Machine） があります。 KVM は、オープンソースでありながら高い性能と安定性を持ち、Linux に深く統合されていることから、多くのオンプレミス環境やプライベートクラウドで採用されてきた実績があります。昨今ではパブリッククラウドが普及したことで、オンプレミスのサーバから GCE や EC2、AVM といったコンピュートマシンへのリフトアンドシフトが進んでいます。 大半の場合、パブリッククラウドが提供するコンピュートマシンは、それ自体が仮想化された VM として提供されます。ここで、従来利用してきた「KVM によるサーバ仮想化はクラウドプロバイダが提供する VM でも利用できるのか」という疑問が生じました。答え、クラウドプロバイダが提供する VM でも Nested Virtualization（Nested V12n） という仕組みを利用できます。 Nested V12n は、その名の通りネストされた仮想化を意味し、VM の中で別の VM を実行（VM in VM）することを指します。 Nested V12n を使用すると、クラウドプロバイダが提供する VM 内で KVM を利用することができます。しかし、実際にはオンプレミスの物理マシンとクラウドプロバイダが提供する仮想マシンでは、KVM の構築に際して仕組み上異なる部分があり、後者の場合は特有の制約もあります。今回のブログでは、Google Cloud の VM（GCE）で Nested V12n を利用し、libvirt を用いて Linux KVM を構築してみたので、クラウドサービスの VM で KVM を実行する方法や、VM ネットワークの違いについて紹介したいと思います。

株式会社 AbemaTV Cloud Platform Team にて ABEMA を構成するマイクロサービスのデプロイ状況を可視化するモニタリングツールの開発・導入ミッションに臨みました。本記事は 「CyberAgent Developers Blog - ABEMA におけるマイクロサービスデプロイ状況可視化のための内製モニタリングツールの開発」 に掲載された内容です。

クラウドサービスや Third-party ベンダが普及する昨今、各サービスを連携する上で、OIDC や OAuth 2.0 という言葉をよく耳にすると思います。これらの仕組みは、サービスを利用する際のセキュリティを担保する上で重要となる、認証・認可を提供するための基本的な規約（プロトコル）になります。OAuth 2.0 や、その仕組みを流用して拡張された OIDC は複雑で、認証・認可において多くのフローを辿ります。毎回、再調査をするのが大変なので、認証・認可の仕組みについて一度整理しておきたいと思います。

現在、研究室で利用するための KaaS 基盤（プライベートクラウド）を整備するべく、ベアメタル Kubernetes の構築に取り組んでいます。今回は、CNCF cloud native landscape にもある Rook/Ceph を使用して分散ストレージシステムを導入し、Amazon S3 や Google Cloud Storage に相当するオブジェクトストレージを自前で構築してみたので、その紹介です。

Kubernetes やクラウドネイティブな環境下での負荷試験において、Grafana Labs の k6 が注目されています。 k6 はコンテナフレンドリーな設計となっており、シナリオの定義も非常に容易です。 また、Kubernetes への導入には、オペレータ（k6-operator）を用いることで、大規模な負荷シナリオや分散実行、自動化されたパイプラインとの統合も可能です。今回のブログでは、モダンな負荷試験ツールである k6 を取り上げ、導入方法や負荷試験環境の構築についてまとめてみたいと思います。

こんにちは！れん（@ren510dev）です。今年も近所の桜が満開で、外に出ると香りが漂ってきます。夜は過ごしやすい気温だし、風も気持ち良いので 最近は毎日 1 時間程散歩をしています。健康に良いし、考えも整理出来るしで一石二鳥！丁度 1 年前の 2022 年 4 月 ~ 2022 年 7 月にかけて、インターンシップを始め就職活動を行い、計 40 社 以上の面談・面接を受けました。結果、多くの企業よりオファーを頂き、インターンの合格通知、内定を獲得することができました。最近では、25 卒の方から、選考対策・就活に関する相談を受けることも多くなってきたので、今回は当時を振りつつ、経験を踏まえてこれから就活を始める人に向けてメッセージを書いてみようと思います。

3 年ぶりに Orenge Diary をフルスクラッチリニューアルしました。これまで、jQuery と PHP をベースに Nginx on KVM（Ubuntu）でセルフホスティングしていましたが、モダンな Web フロントアーキテクチャを目指して Next.js へリビルドし、Vercel に移設しました。今回のブログではポートフォリオサイトのリビルドについて軽く紹介したいと思います。

Next.js は、React ベースの Web アプリケーションフレームワークで、SSR（Server Side Rendering）等のフロントエンド開発に必要な機能を十分に備えています。 2022 年 10 月には、App Directory（App Router）というルーティングエンジンを beta 版として導入した Next.js 13 がリリースされました。今回のブログでは、Next.js 13 の基本的な考え方と使い方について整理してみたいと思います。

従来、Kubernetes では秘匿情報を管理するコンポーネントとして KES（Kubernetes External Secrets） が広く利用されており、Secret リソースを管理するツールとしてデファクトスタンダートとなっていました。 しかし、2021 年 11 月 KES の非推奨化が発表され、2022 年 7 月時点でアーカイブされました。KES が非推奨になった背景としては、アクティブなメンテナがいなかったことや、プロジェクト内で抱えていた技術負債を解消しきれず、メンテナンスのモチベーションを維持できなかったことが言及されています。KES の非推奨化に伴う後継ツールの一つとして ESO（External Secrets Operator） が注目を集めています。 ESO は KES を開発していたコミュニティによってホスティングされており、Go でリファクタリングされています。 ESO は KES との互換性を維持しつつ、メンテナンス性を重視した機能豊富なサービスとなっており、移行ツールも用意されています。今回のブログでは、KES の非推奨化に伴う ESO への移行について、ツールの特徴を交えながら紹介したいと思います。

Ubuntu 22.04（LTS）がリリースされたのでインストールしてみましたが、そのまま放置して数ヶ月が経っていました。 久しぶりに使用する場面が来たので、いつも通り apt update しようとしたところ、『Warning: apt-key is deprecated』というメッセージが表示されました。Debian 12 からは、apt パッケージの署名に利用している apt-key が非推奨・廃止になるとのことです。しかし、今のところ、apt-key に変わる、apt リポジトリの署名に使用する GPG 公開鍵の管理手法におけるベストプラクティス的なものが無かったので、とりあえず、GnuPG（gnupg + signed-by） で移行してみました。

Go 1.18 は「our biggest change ever to the language」と言われるほど、Go 言語誕生以来、最大の仕様拡張が行われました。中でも、netip パッケージの登場は Go でネットワークプロトコルを書いている身として非常に画期的だと思いました。今回のブログでは、netip の導入背景を踏まえ、パッケージの特徴、互換性、メソッドの使い方等、従来の net パッケージと何が変わったのかを紹介したいと思います。

ゲーマー向けのテキストチャットサービスとして有名な Discord は、内部コンポーネントの一つである「Read States」を Go から Rust に再実装し、パフォーマンスが大幅に向上したことを発表しました。Discord のホットパスである「Read States」は、特に膨大なリクエストを捌く必要があり、システム自体に高いパフォーマンスが要求されるコンポーネントだそうです。 これまで、Discord の大部分は Go で実装されていましたが、2020 年初頭に Rust へ移行したことが明らかになりました。最近、Rust のキャッチアップをしていることもあり、なぜ、Discord は Go から撤退して Rust を採用したのか気になったので、公式ブログ を参考にまとめてみたいと思います。

Web サーバやミドルウェアには、同時に多数の接続を効率的に処理することが求められます。 特に、インターネットの普及に伴い Web サービスの利用者が増加し、膨大なクライアントからのリクエストを処理する必要性が高まっています。Apache に代表される、スレッド（プロセス）駆動ベースのソフトウェアアーキテクチャは、増大するクライアントに対するリソースの消費傾向やコンテキストスイッチのオーバーヘッドが増大することで、スケーラビリティの課題があります。このような課題は、一般に C10K（同時に 10,000 接続を処理する）問題 と称され、2000 年初頭から、従来のソフトウェアの潜在的な課題を解決する効率的なアーキテクチャの必要性が議論されるようになりました。近年では、ソフトウェアにおけるイベント駆動ベースのアーキテクチャが注目され、Nginx のような新世代の Web サーバも登場しました。今回のブログでは、スレッド駆動ベースの Apache と イベント駆動ベース Nginx を例に、スレッド駆動アーキテクチャとイベント駆動アーキテクチャの特徴や、それぞれの技術的な問題点・利点について紹介したいと思います。

Go を書いたことがある人なら、Goroutine というワードを耳にしたことがあるかと思います。Goroutine とは、Go で並行処理を実現するための軽量なスレッドのことです。Goroutine は一般的なカーネルスレッドと比較して、非常に軽量かつ効率的なスケジューリングが可能です。今回のブログでは、Go ランタイムの仕組みを覗き Goroutine が '軽量スレッド' と呼ばれる理由についてまとめてみたいと思います。

ネットワーク経路上のルータ（ソフトウェアルータ）をはじめとし、ロードバランサやキャッシュサーバ等のミドルウェアは、特に高いパケットレートを処理する必要があります。 これらのシステムは、膨大なパケットを迅速かつ効率的に処理するために、物理および論理の両方で高いパフォーマンスが要求されます。ネットワークトラフィックの処理は、コンピュータシステムにとって非常にリソース集約的な作業であり、高パケットレート環境下では CPU に掛かる負荷が非常に大きくなってきます。 ネットワークミドルウェアでは、多数のクライアントからの要求を捌くために、マシン内の処理に起因する負荷を効率的に分散・軽減させる必要があります。アプリケーションをマルチコア環境でスケールさせる際、CPU 負荷が特定のコアに集中することでシステム全体のパフォーマンスが低下する場合があります。 この問題を解決するため、Linux ネットワークスタックの NAPI や NIC のオフロード機能が、CPU の割り込み処理を効率化し、パフォーマンスを最適化する上で重要な役割を果たします。また、マルチコアスケーリングを効果的に実現するためには、NIC の RSS やカーネルの RPS/RFS といった機構も活用する必要があります。 これらの技術により、パケット処理を複数の CPU コアに分散させ、システム全体のパフォーマンスを最適化することが可能です。今回のブログでは、高パケットレート環境下において膨大なリクエストデータを捌くために Linux カーネルが取った対策について紹介したいと思います。

このブログは『Raspberry Pi で構築する Bare-Metal Kubernetes』のエコシステム編です。 準備編では、機器類の準備、セットアップ、各種 OSS の選定と全体設計について紹介しました。 また、構築編では Kubernetes クラスタを構築し、アプリケーションをデプロイして MetalLB で公開しました。エコシステム編では、より本番環境に近い Kubernetes の運用を目指すべく、モニタリング基盤と ArgoCD による GitOps を整備したいと思います。

このブログは『Raspberry Pi で構築する Bare-Metal Kubernetes』の構築編です。 準備編では、機器類の準備、セットアップ、各種 OSS の選定と全体設計について紹介しました。構築編では、セットアップした Raspberry Pi に Kubernetes をインストールして Control-Plane 1 台、Data-Plane 3 台のクラスタを構築し、アプリケーションをデプロイして公開してみます。 本記事では MetalLB の仕組みについても簡単に紹介します。

クラウドネイティブ に注目が集まる昨今、コンテナオーケストレーションツールとして Kubernetes がデファクトスタンダードな基盤技術となっています。Kubernetes を用いることで 宣言的な設定（Declarative Configuration）に基づいたアプリケーションのデプロイ、管理、運用の自動化、スケーラビリティの確保等を実現することができます。Kubernetes によりサービス運用の効率化や高度な自動化を実現できますが、内部のアーキテクチャは非常に複雑なものになっており、コンピュータサイエンスの基本的な知識も必要になります。運用に際して、インフラエンジニアやクラスタの管理者は Kubernetes の内部コンポーネントの詳細や、その挙動を熟知しておくことが重要です。Kubernetes の有名な学習リソースの一つに Kubernetes The Hard Way というものがあります。これは、手作業で一からクラスタを構築して Kubernetes の内部構造への理解を深めるというコンテンツです。Kubernetes The Hard Way では、主に GCP の Compute Engine を用いますが、今回は Raspberry Pi をベースにベアメタルでクラスタを構築してみました。いわゆる『おうち Kubernetes』というやつです。今回は、Raspberry Pi で Kubernetes をセルフホスティングする方法について『準備編』『構築編』『エコシステム編』の 3 編にわたり紹介したいと思います。準備編では、機器類の準備、Raspberry Pi の初期設定をします。また、Kubernetes の構築に必要となる各種 OSS の選定や、ネットワーク構成およびインフラ全体の設計について固めます。

Go で競技プログラミングに臨んだことがある人なら、一度は fmt.Scan 関数の落とし穴にハマったことがあるのではないでしょうか。 Go では標準入力を受け付ける際に、fmt.Scan 関数、もしくは bufio.Scanner メソッドや bufio.ReadLine メソッドをよく用います。 しかし、Go を使って競技プログラミングをやる場合、bufio.Scanner を使用しなければ困る場面があります。 今回のブログでは、fmt パッケージの Scan 関数と bufio パッケージの Scanner メソッドに注目しながら、fmt.Scan で TLE が発生する原因と解決策について紹介します。

インターネットを介して提供されるサービスはどのように構築・実現されるのでしょうか。現代のネットワークアプリケーション開発において、Socket API は非常に重要な役割を果たします。 Socket API は、異なるコンピュータ間でデータを送受信するための低レベルインターフェースを提供し、TCP/IP に則った通信を実現します。今回のブログでは、ネットワークソケットについて触れ、Socket API の概要から実際の使用法について紹介します。

インターネット上には様々な脅威が存在するため、端末間通信におけるセキュリティの確保が重要です。異なるプライベートネットワークに存在する端末同士をセキュアに接続する代表的なネットワーク技術として VPN（Virtual Private Network）があります。VPN は、公共ネットワーク網の中に仮想的な専用線を作り出し、送受信データを暗号化することでグローバルネットワークを介したセキュアな端末間通信を実現します。VPN を使用すると、オフィスと自宅、異なる拠点同士等、地理的に離れた場所にあるプライベートネットワーク同士が直接繋がっているかのようなエンドツーエンド通信が可能になります。近年では、クラウドサービスや IoT（Internet of Things）の普及、リモートワークの一般化が進み、ネットワークの構造は複雑で分散的なものになってきています。こうした背景を踏まえ、VPN を用いた安全かつセキュアなリモート接続は組織や企業においてますます重要な役割を担います。今回のブログでは、VPN を利用することで地理的に離れた端末同士をセキュアに繋げられる仕組みや要素技術、VPN の代表的な接続トポロジについて紹介したいと思います。

L2 モデルによるネットワーク設計は拡張性や高可用性の観点から、DC の弱点とされてきました。 これは L2 で使用されるプロトコルが多数のデバイス間でトラフィックを大量に送信するため、冗長化構成を取りながらもフレーミングストームを回避するための策を講じる必要があったためです。 また、従来のネットワークトポロジは、スケールインモデルであることから、ネットワーク帯域を拡張する際は、より大きくて高価な機器に交換します。 さらに、大きな機器ほど多くの機器と接続するため、故障した際の影響範囲が大きくなることが懸念されます。 そのため、DC ネットワークは拡張に伴いますます複雑化し、運用面やコスト面においてスケーラビリティは限界を迎えようとしていました。近年では、これらの問題を受け、多くの DC で IP-Clos と呼ばれる、Clos ネットワークの原則を適用した IP-fabric が採用されています。 Clos ネットワークは、L3 ベースのアーキテクチャを用いることで、ブロードキャスト等の BUM トラフィックによる帯域圧迫を排除し、安定性と拡張性を向上させます。 また、BGP と BFD はベンダに依存せず、L3 で経路を制御するため、トラブルが発生した際も、従来の IP のトラブルシューティングが適用可能になります。今回のブログでは、実際に日本で IP-Clos が採用されているヤフーにて Clos ネットワークの構築を経験してきたので、これを機に聞いた話や知見を含め、IP-Clos について調査・紹介しようと思います。

インターネットを介した通信は、WEB サービス、モバイルアプリケーション、IoT 等、様々な分野で利用されています。ネットワークアプリケーションの多くは Internet Protocol（IP）と呼ばれる仕組みによって実現されています。IP による通信は、データを相手端末に送り届けるための最も基本的な方式であり、現代のインターネットそのものを成り立たせています。本来、IP 通信はエンドツーエンドの接続性、すなわち送信側と受信側が直接データをやり取りできることを前提に設計されています。しかし、実際のインターネット環境では IP 通信を妨げる様々な障壁が存在するため、単に IP アドレスを指定すれば相手と接続できるというわけではありません。特に IP によるエンドツーエンド通信の大きな障壁となっているのが、NAT/NAPT やファイアウォールの存在です。これらは、ネットワーク内のセキュリティ確保や IP アドレスの節約 といった目的で広く導入されています。一方で、NAT/NAPT は、配下の端末を外部から隠蔽する特性があり、「どのように相手と接続するか」という接続性の問題を引き起こします。今回のブログでは、IP 通信の発展と課題、それらの課題を解決するために登場した代表的な通信接続性を実現する技術について紹介したいと思います。

ソースコードだろうと論文だろうと VSCode で全てを完結させたい！今回は、mactex-no-gui というパッケージを導入して VSCode に Tex 環境を構築してみました。

今日、インターネットは電気や水道と同じく日常に欠かせないインフラとなっています。 我々はスマートフォンやパソコンといったネットワーク機器を Wi-Fi やモバイル回線（5G や LTE）に接続することで、インターネットを通じて世界中の人と容易に繋がることができます。では、インターネットは一体どのようにして我々のもとに情報を届けているのでしょうか？今回のブログでは、インターネットやコンピュータネットワークの仕組みを紹介します。

Shell Script は UNIX 系システムにおいて高度な自動化を実現するための非常に強力なツールで、トイル（Toil）の撲滅に繋がります。トイルとは、反復的で非創造的な作業のことを指します。 これには、例えば、手動でのシステムのスケーリングや、エラーのトラブルシューティング、ルーチンメンテナンス等が含まれます。 トイルを特定し、それを自動化することで、エンジニアはより創造的なタスクやプロジェクトに焦点を合わせることができます。O'Reilly の Site Reliability Engineering 本によれば、トイルを判別する方法として、次のような基準が挙げられています。上記の項目に該当する作業は、Shell Script による自動化によって効率よく軽減することが可能です。今回のブログでは、Shell Script を使った効率的な自動化の実践方法と、トイルを削減するベストプラクティスについて、Google から提供されている Shell Style Guide を参考に紹介したいと思います。

2020 年 11 月〜2021 年 3 月の約 5 ヶ月間、株式会社サイバーエージェント が企画する長期育成型プログラム CA Tech Accel という企画に参加をしたので、取り組んだこと、成果についてアウトプットしてみようと思います。

開発の中で Linux 環境での検証が必要になったので、macOS に VirtualBox をインストールし、Ubuntu を仮想マシンとして立てて利用していました。 ところが Docker を多用していたところ、Docker イメージが思いの他ストレージを占領するため、あっという間にオーバーフローしました。 ということでそれまで 20 GB の仮想 HDD をアタッチしていましたが、これを機に一気に 64 GB までストレージを拡張していきたいと思います。今回は調べた内容を元に、Ubuntu 仮想マシンのストレージ拡張方法 について書き残しておきたいと思います。

ハードウェアリソースを最大限に活用し、柔軟かつ効率的なシステムの運用を実現するために「仮想化技術」は必要不可欠となっています。今回のブログでは、仮想化技術の基本的な仕組みや必要性、メリットに触れ、Oracle VM VirtualBox を使って実際に仮想マシンを構築してみたいと思います。